Distributed computer systems have multiple computing devices interconnected via one or more networks (or other type of connection) to facilitate a common computing experience. There are many examples of distributed computer systems, including such well-known examples as the client-server architecture, the mainframe-terminal architecture, computer clustering architecture, and so forth.
Software implemented by a distributed computer system is typically distributed throughout the various computing devices, whereby different computers handle different computing tasks. Object oriented programming, for example, can be implemented on a distributed computer system using an extension of the component object model (COM), which is often referred to as “DCOM” (for Distributed COM) or “Network COM”.
Object-oriented programming utilizes the concept of “objects” and “object interfaces” to specify interactions between computing units. An object in this context is a unit of functionality that implements one or more interfaces to expose that functionality to outside applications. An interface is a contract between the user, or client, of some object and the object itself. In more practical terms, an object is a collection of related data and functions grouped together for a distinguishable common purpose. The purpose is generally to provide services to remote processes. An interface is a grouping of semantically related functions through which a remote process can access the services of the object. COM has been well documented. For more information regarding COM, the reader is directed to OLE 2 Programmer's Reference and Inside COM, both published by Microsoft Press of Redmond, Wash.
FIG. 1 shows an exemplary client-server architecture 100 in which a client computer 102 occasionally connects to a file server computer 104 via a network 106, such as a LAN (local area network) or WAN (wide area network). For discussion purposes, suppose the architecture 100 implements object-oriented applications according to the distributed component object model. DCOM specifies how objects at the client 102 and server 104 interact with each other over the network 106. To a client process, the object appears to be readily available, as if it were running on the same computer. In reality, however, the object might be running on a computer that is remotely located and only accessible over the network.
Calling a remote interface (one that is in a different address space than the calling process) requires the use of remote procedure calls (RPCs), which involve “stubs” and “proxies,” and topics such as “marshalling” and “unmarshalling” of procedure parameters. These mechanisms are well understood and are documented in the books mentioned above. In regard to these topics, the reader may also want to refer to “X/Open DCE: Remote Procedure Call,” published by X/Open Company Ltd., U.K.
In this example, the client-server architecture 100 implements a “state-based” architecture, meaning that the file server 104 maintains state information on behalf of the client. State information pertains to the operations and tasks being performed for or during a particular client-server computing experience. Typically, state information includes one or more identities of participating computers, status of tasks/operations being performed, data being generated, and the like.
In FIG. 1, the client 102 and file server 104 maintain a connection until the entire session is completed. Thus, there may be many communications going back and forth between the client and server during the connection session. In the DCOM context, the communication is in the form of RPCs from the client 102 to remote objects on the server 104. The file server 104 maintains the state information during the connection session.
One problem with the state-based architecture of FIG. 1 is that it does not scale well to accommodate increasingly larger numbers of clients. The file server effectively dedicates resources to a requesting client until that client finishes, thus preventing reallocation of resources to other requesting clients. Additionally, tracking state information on the server for increasingly more clients becomes burdensome on the file server's ability to respond quickly to client requests.
In contrast to state-based architectures, “stateless” architectures do not explicitly keep state information at the file server. FIG. 2 shows an exemplary stateless client-server architecture 200 where a client 202 communicates with a file server 204 over a network 206. The network utilizes a communication protocol that is specially designed to permit the network file server 204 to pass data and state information to the client 202, thereby alleviating the file server 204 from maintaining the state information. A further benefit of “stateless” architectures is that client requests can be sent to any number of identical, replaceable servers, because no single server retains the server state. Instead, the state travels with the client request. One example of a domain-specific stateless communication protocol is the NFS (Network File System) protocol common among UNIX-based network file servers.
Prior art stateless architectures, however, are plagued by the problem that they are limited to domain-specific protocols that prescribe precise protocol-specific state to be exchanged between the client and the server. This makes incremental upgrades of the protocols more difficult because all computers—both clients and servers—must be updated anytime the protocol is modified. Furthermore, it limits the advances that can be made on the server code since the server cannot add new state to the protocol without a pre-existing agreement covering protocol architecture with the client. Accordingly, there remains a need to develop a stateless architecture that is not tied to domain-specific protocols—an architecture in which a server can add arbitrary state to the protocol at anytime without requiring parallel changes to the client.
The Internet's HTTP (hypertext transport protocol) offers one compelling example of a stateless architecture that does not rely on domain-specific state-exchanging protocols. FIG. 3 shows an Internet-based client-server architecture 300 where a client 302 communicates with a Web server 304 via the Internet 306. With HTTP, a browser on the client 302 submits a request to the Web server 304. In response, the Web server 304 processes the request and returns a reply. Originally, there was only one request and one reply per client-server interaction. The Web server had no way of associating consecutive reply/request sets with any one particular client. Thus, if the client subsequently submitted a request, the Web server 304 was incapable of distinguishing whether the request came from the same client or a different client.
To solve this problem, the server began returning data along with the reply that could be used to identify the client. The data piece, commonly referred to as a “cookie”, originally included just a user or client ID. Today, cookies can hold essentially any type of date and typically include a name, data, an expiration period, and a scope (e.g., “//msn.com/bookstore/compsci”).
The contents of a cookie originate within a request on the server. The cookie is passed to the client along with the client's request. The client returns the cookie with subsequent requests to the server. To the client, the cookie is an obscure piece of data that resides in memory, perhaps indefinitely (or until deleted as being expired). However, the cookie allows the server to offload storage of state information to the client, who owns a vested interest in preserving relevant state.
As a result, Web servers achieve tremendous scalability to accommodate increasingly more traffic. State-storage capacity, in the form of client-cached cookies, scales linearly with increasing numbers of clients, while access time remains constant. Furthermore, individual servers can be replaced or replicated with greater freedom when no single server hoards state related to a specific client. For more discussion of cookies, the reader is directed to an IETF (Internet Engineering Task Force) specification entitled “HTTP State Management Mechanism”, which was published February 1997.
In view of the foregoing discussion, there remains a need for a stateless architecture in a non-HTTP-based distributed computing environment that achieves scalability without utilizing domain-specific protocols.